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ABSTRACT 



A system is provided for executing and debugging multiple 
codes in a multi-architecture environment that includes a 
real X architecture (domain) and a simulated (Y) ardiitcc- 
ture (domain). The multiple code executing and debugging 
system comprises an X conqnatcr system having a memcsy 
with stored X and Y code and having the X architecture 
embodied therein. 

A detector is provided to detect calls from executing code in 
cither domain for cross-domain services including execution 
of cross-domain routines. A jacketing system jackets cross- 
domain routine calls to interface the calling conventions of 
the calling and the caUed routines. 

18 Claims, 8 Drainng Sheets 
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SYSTEM FOR EXECUTING AND 
DEBUGGING MULTIPLE CODES IN A 
MULTI-ARCHITECTURE ENVIRONMENT 

USING JACKETING MEANS FOR 
JACKETBVG THE CROSS-DOMAIN CALLS 

CROSS REFERENCE TO RELATED 
APPLICAnONS 

This application is a continuation of application Ser. No. 
08/264^13, now abandoned, filed Jun. 17. 1994. wliich is a 
continuation of ^plication Ser. No. 07/666,039, filed Mar. 
7, 1991, now abandoned. 

Reference is made to the following concurrently filed 
patent a|}plications assigned to the present assignee and 
hereby incorporated by reference: 
Ser. No. 07/666.028, filed Mar. 7, 1991, now abandoned, 
entitled SYSTEM AND METHOD FOR AUTOMAH- 
CALLY INTERFACING CALL CONVENTIONS 
BETWEEN TWO DISSIMILAR PROGRAM UNITS and 
filed by Daniel L. Murjrfiy. 

Ser. No. 07/665,888, filed Mar. 7, 1991, now abandoned, 
entitied IMPROVED SOFTWARE DEBUGGING SYS- 
TEM AND METHOD ESPECIALLY ADAPTED FOR 
CODE DEBUGGING WITHIN A MULTI- 
ARCHITECTURE ENVIRONMENT and filed by James A. 
Wooldridge, Ronald F. Brender and Henry N. Grieb, IIL 
Ser. No. 07/666.022, filed Mar. 7, 1991, now abandoned, 
entitled IMPROVED SIMULATOR SYSTEM AND 
METHOD ESPECIALLY ADAPTED FOR CODE 
EXECUTION IN A MULTt-CODE EXECUTION AND 30 
DEBUGGING SYSTEM WITHIN A MULTI- 
ARCHTTECTURE ENVIRONMENT and filed by Mark A, 
Herdeg and Michael V. lies. 

Ser. No. 07/666,072, filed Mar. 7, 1991, now abandoned, 
entitled IMPROVED SYSTEM AND METHOD FOR 35 
DETECTING CROSS-DOMAIN INSTRUCnON CALLS 
AND DATA REFERENCES ESffiCLflJ^LY ADAPTED 
FOR CODE INTERFACE JACKETING IN A MULTI- 
CODE EXECUTION AND DEBUGGING SYSTEM 
WITHIN A MULn-ARCHTTECTURE ENVIRONMENT 40 
and filed by Mark A. Herdeg. Scott G. Robinson, Ronald F. 
Brender and Michael V. lies. 

Ser. No. 07/665,752, filed Mar, 7, 1991, now U.S. PaL No. 
5,339,422, entitled IMPROVED SYSTEM AND METHOD 
FOR JACKETING CROSS-DOMAIN CALLS IN A 45 
MULTI-CODE EXECUnON AND DEBUGGING SYS- 
TEM WTTfflN A MULTI-ARCHITECTURE ENVIRON- 
MENT and filed by Ronald E Brender and Michael V. Hes. 
Ser. No. 07/665,886, filed Mar. 7, 1991, now abandoned, 
whidi is entiUed FASTER PROCESS FOR DEVELOPING 50 
NEW COMPUTER SYSTEMS EMPLOYING NEW AND 
BETTER PROCEDURES FOR SOFTWARE DEVELOP- 
MENT AND TESTING and filed by Robert V. Landau, 
James E. Jdinson aiid Michael V. Hes. 
Reference is also made to the following concurrently filed 55 
patent applications assigned to the present assignee: 
Ser. No. 07/666,071, filed Mar. 7, 1991, now abandoned, 
entitled IMPROVED SYSTEM AND METHOD FOR PRE- 
SERVING INSTRUCnON STATE-ATOMICITY FOR 
TRANSLATED PROGRAM CODE and filed by Scott G. 6o 
Robinson, Richard Sites and Richard Witek. 
Ser, No. 07/666,025. filed Mar. 7, 1991, now U.S. Pat No. 
5,307,504, which is hereby incorporated by reference and 
which is entitied IMPROVED SYSTEM AND METHOD 
FOR PRESERVING INSTRUCHON GRANULARITY 65 
FOR TRANSLATED PROGRAM CODE and filed by Scott 
G. Robinson and Richard Sites. 
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BACKGROUND OF THE INVENTION 

The present invention relates to systems and methods for 
executing and debugging multiple codes in a multi- 
architecture environment and, more particularly, to 
5 improved multi-code execution systems and methods that 
operate with better flexibility and provide improved execu- 
tion and debugging for new program codes developed for a 
new architecture t>efore the hardware and operating system 
for the new architecture are available. 

A large amount of development effort and monetary 
investment is required to design a new con^)Uter hardware 
ardiitecture, develop a commercial computer product imple- 
menting the new architecture, and develop system and user 
software for use on the new con^uter product As the time 
to develop new computer hardware and software increases, 
both the product investment cost and the product madxt- 
ability may be adversely affected. Hius, greater comm^rciai 
product development time usually requires more monetary 
investment by the manufacturer and its suppliers and users 
and, further, runs greater risk that anticipated market needs 
and other market conditions will have eroded before the new 
product is commercially available. 

In any case, for economic and other reasons it is desirable 
for and beneficial to suppliers, manufacturers and users that 
the total hardware/software development time cycle be 
shortened. Significant development cycle shortening is 
achieved by a new process set forth in the cross-referenced 
application Ser. No. 07/665,886, now abandoned, in which 
hardware and software development processes can be run 
substantially concurrently rather than sequentially. The 
present invention is directed to system structure and pro- 
cesses that help shorten such development cycle shortening. 

Some prior art tcdmology has been available to allow 
limited development of software and hardware in parallel 
activity for a new computer hardware architecture. For 
exan^le, simulators have been employed to emulate new 
hardware on existing hardware and thereby provide a limited 
working environment for software engineers who are 
responsible for writing new programs or migrating other 
programs to the new environment. 

The relevant prior art technology, however, has limited 
utility because it addresses only the needs of developers of 
low level software and the operating system itself. No 
mechanism is provided for test execution of user level 
software which requires lower level and support software to 
be operable in the simulated environment or on the real 
hardware. In particular, an operating system and library 
support routines for the new ardiitecture arc normally not 
available as operating coii^)onent5 of the simulator, thereby 
making the execution of user level software for the new 
architecture impossible. The operating system and higher 
layered software itself can be simulated but this alternative 
is very costiy and complicated. 

The present invention is directed to resolving these prob- 
lems by providing a total architecture environment within 
whidi code for existing hardware and new user level and 
other code for new hardware can be executed to enable new 
code testing and debugging before the new hardware and an 
operating system and support software fcH" it are available. 
Basically, a system or method in^lemented in acccx-dance 
with the invention provides mult^lc code execution in a 
multi-architecture environment whidi may include an exist- 
ing hardware environment and a simulation environment 
that employs the underlying operating system and support 
software employed in the existing hardware enviromncnt 

SUMMARY OF THE INVENTION 

A mixed code image is created for execution in a multiple 
code execution system that provides a multi-architecture 
environment including a real X ardiitecture and a simulated 
Y architecture. 
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A pair of jacket descriptioiis defines the calling conven- environment. An X processor 12 forms a part of a real X 

tions for incoming and outgoing calls for each routine in an architecture that provides for the execution of multiple codes 

X code module as well as for each routine in a Y code including X code 18. 

module to be executed by the execution system. X jacket GencraUy, the system can be operated to process and 
objects and Y jacket objects are compiled from the jacket 5 execute multiple codes, but in the prefened embodiment, the 

descriptions, and each of the jacket objects includes a jacket system 10 is structured for executing up to two codes: X 

table embodying the cOTresponding jacket descriptions for code 18 and another code for a simulated hardware which 

each routine. code is designated as Y code 20. The system 10 may direcfly 

X objects are conq)iled from the X code module and Y execute a new user application level or other program 
objects arc compiled from the Y code module. The X objects 10 compiled in or translated to Y code and, in doing so, make 

and the X jacket objects are linked to produce an X image. use of X operating system and support software. 

An X image is further generated to include a multiple An X loader 16 provides for program code entry into a 

code execution and debugging system, and the Y objects and memory system 14 (FIG. 2) within which various program 

Y jacket objects are linked to produce a Y image. The X and and data components of the system 10 are stored for execu- 

Y images are activated for execution in the execution tion. A general layout is shown in FIG. 2 for programs 
system. contained in the memory system 14. Various memory comr 

The multiple code execution and debugging system ponents are indicated as functional block components in 

includes environment manager and simulator con^>onents FIGS. 1 and 3. 

and may further include a debugger component ^th use of the code translation system and method 

The operating aspects of the invention are directed to the disclosed in the cross-referenced applications Scr. Nos. 

functioning of the multi-code execution system on an X 07/666,071 now abandoned, and 07/666,025, now as U.S. 

con^utCT. Hie simulator coiiq)onent simulates the Y archi- Pat No. 5307,504 user application level and other X 

tecture on the X computer. If provided, the debugger com- programs can be translated to functionally equivalent Y 
ponent is operated to debug X code and Y code in the ^ programs. As an illustrative application of the present 

multi-architecture environment. Hie environment n:ianaga invention, such Y programs can be executed on real X 

component manages the operation of the simulator and hardware by the system 10 for testing and debugging 

debugger components and the X con^juter system to provide purposes even though operable Y hardware is unavailable, 

mixed X and Y code execution and debugging. Advantageously, an X program can be partially translated 
BRIEF DESCRIFnON OF THE DRAWINGS 30 ^program code, or a new program can be partially written 

in Y code for execution with supporting or other X program 

The accompanymg drawmgs, which are incorporated in code, and the mixed X-Y program code can be executed by 

and constimte a part of this spedflcation illustrate one the system 10 for testing and debugging of both Ae X and 

embodiment of the mvention and together with the descrip- y codes. The Y code is executed, tested and debugged on tiie 

tion provide an explanation of tiie objects, advantages and simulated architecture, and the remaining X code is 

principles of tiic mvention. In tiic drawings: executed, tested and debugged on tiie native architecture. 

FIG. 1 shows a functional block diagram of a system for With successful testing of the existing Y code, additional 

executing and debugging multiple codes in a multi- segments of X code can be translated for stepped Y code 

architecture environment in accordance with the present testing and debugging until the X code is fully translated and 

invention; ^ UieY code testing and debugging is completed. the use 

FIG. 2 shows a diagram representing a general program of progressively stepped testing and debugging, the entire 

memory layout for the system of FIG. 1; testing and debugging process is facilitated. 

FIG. 3 shows a functional block diagram representing the Overall, a program can be executed and tested for the Y 

process by which programs are created for the multi- architecture by translating or compiling it into Y code and 

ardiitecture system of HG. 1; running the Y code on the callable system simulator. The 

FIG. 4 shows a flow chart for a simulator/debugger driver run-time environment for the Y code is provided by the 

loop cissploycd by an environment manager in the system of operating system and run-time libraries executing on the X 

FIG. 1; or native hardware architecture that is included in the 

FIG. 5 shows a diagram illustrating cross-domain switch- multi-architecture systenL The composite software thus 
ing operation of the system of FIG. 1. 50 includes X and Y codes that are properly executed on die 

FIG. 6 shows a functional block diagram for a cross- combined X (real) and Y (simulated) architectures. In die 

domain call detection system enc^loyed in the system of preferred embodiment described herein, the operating sys- 

FIG. 1; t^ni for the composite software system is structurally 

FIG. 7 shows a functional block diagram for a call included in tiie X domain, 
jacketing system employed in the system of FIG. 1; 55 The partitioning of code between die real and simulated 

FIG. 8 shows a functional Wock diagram representing the architectures is generally open to the system user's needs, 

software and hardware structure of a callable simulator and example, the code boundary can be between the program 

related system components employed in the system of FIG. being ported and the X operating system or, as indicated 

1; and above, it can even be within the program being ported, 

FIG. 9 shows a functional block diagram representing the ^ software system 100 generally has application to 

software and hardware structure of a debugger employed in widely different architectures. The system 10 also has appli- 

the system of FIG. 1. cation to architecture-in^lementation systems that have 

DESCRIFnON OF THH PRFPFRRFH <Mcrciit operating systems and different calling systems, but 

DESCRlFrrc^OFTraEP^^ g^^j^ appUcation is facilitated if tiie architecture- 

liMiSUDIMENT iiiq)lementation systems have similar operating systems and 

There is shown in FIG. 1 a system 10 that is arranged to similar calling standards. Reference is made to the cross- 
execute and debug multiple codes in a multi-architecture referenced appUcation Ser. No. 07/665,752, now U.S. Pat 
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No. 5339,422, for additional background infonnatioii on that constitute the simulated architecture domain arc main- 
calling systems and differences among them tained for the environment manager 102 by a facility housed 
FIG. 1 shows the architecture of a software system 100 in the simulatcr 104, Callable routines arc provided for 
which can be executed by the system 10. A callable simu- initializing the Y domain, adding to the Y domain, and 
lator 104 functions as part of software system 100 (FIG. 1) ^ querying whether a particular address is within the domain, 
within a second architecture (domain), which is preferably a Cross-domain data references from the X domain are 
Y architecture embodied in the X hardware. The simulator made directly since memory data is globally accessible. 
104 is structured to emulate Y hardware on the X hardware However, in the present embodiment, Y domain references 
that may be under development and unavailable. In the to X memory are processed through the enviromnent man- 
preferred embodiment, a callable simulator 104 functions lo ager 102 for jacketing, 
within a second envhronment (domain), i.e. , a Y architecture 

that is embodied in the X hardware. The simulator 104 is DRIVER LOOP 

stmcturedtoemulate Y hardware (that may be under devel- _^ . - _ i_ ^ . ^ . , , . < 

opment and unavailable) on the X hardware. Generally, the , ^^'^ f. ^^^^T ^^/^^ (iiver loop 112 which 

simulator 104 executes Y instructions on caU from X code 15 the ^ulaUon/deb^^^ operation. Entry ^ made to 

through an enviromnent manager 102. CaUs may also be ^V"*"^ I r ^^^^s^omain caU from X 

madefromthe Ycodethroughtheenviromnentmanager 102 ^^^^ often X W-^cation code for execuUon of a Yroutme 

for X code execution. For example, the Y code may repre- ^ughte jacketing system 108 Jacketo^^^ inter- 

sent a user level appUcation j^ogram and may caU for ^^J^"" ^ ^ codes to adjust for calhng 

execution of a routine that is located in an X horary, or it 20 s^ndard <mierences. 

may make a call requiring operating system processing in ^ mixed code applications, cross-domain routine calls 

the X domain. For a detailed description of the structure and ^^m the X domain are made by X aj^lication code. In the 

operation of the simulator 104, reference is made to the case of single Y code execution, a suitable X startup mecha- 

cross-referenced appHcation Scr. No. 07/666,022, now aban- ^^^m initiates Y code execution. 

doned. 25 Jn block 120, parameters are set up and in particular X 

A debugger system 110 also operates under control of tfie parameters arc placed in appropriate Y locations for use 

environment manager 102. In its total operation, the debug- during Y code execution as part of the jacketing process. For 

ger system 110 provides tiie user with control over the whole normally jacketed cross-domain calls for routines, jacketing 

execution of code in either domain so that the execution tables are referenced to determine where parameters come 

process may be examined and modified to ccnrect malfunc- ^^om in the X domain and where the corresponding values 

tions. Generally, the debugger 110 is structured for interac- "lust be placed in the Y domain. For auto-jacketed cross- 

tion with the callable simulator 104 and provides the pro- domain calls for routines^ standard call rules are embedded 

cedures needed for debugging operations such as setting ^ special code for this purpose in the jacketing system 108. 

hrcaigpoints in both the X and Y domains. Mort detail on jacketing for domain interface purposes is set 

The dcbugga 110 can be turned on and off by user ^ cross-referenced application Ser. No. 07/665, 

selection. When the debugger 110 is activated, code execu- "^^2' 5339,422. 

tion is controlled by the setting of breakpoints. For example, A distinguished return address is placed in the standard 

the code may be executed to a point where it is believed a return-address register. The distinguished address is outside 

problem may exist and, with the execution stopped, pro- the address bounds previously established as containing Y 

gram state and data state can be examined for errors. ^ code. It must also be different from an address that might be 

Reference is made to the cross-referenced application Ser. encode a Y-X calL 

No. 07/665,888, now abamloned, for a detailed description In functional block 122, a string variable named ENV_ 

of the structure and operation of the debugger system 110. CMD is maintained in an enviroimdent manager buffer and 

The environment manager 102 interfaces the domains for 45 default to RUN mode (continuous instruction 

aoss-code caUs- Thus, a aoss-domain call detector system execution). It can be set to STEP mode (instruction-by- 

106 is eii^)loycd by the environment manager 102 to deter- instruction execution) by a user selection from the debugger 

mine when a cross-domain call is made during the execution l^^- example, the user may dcddc to perform maintc- 

of either the X code ox the Y code. An X-Y jacketing system i^^^e on the particular Y routine that has been called by an 

108 operates within flie environment management system to 50 ^ routine, and accordingly may make a STEP mode 

provide the X and Y executable instruction interfadng selection for the Y domain. 

needed to inclement aoss-domain calls between routines. The simulator 104 is called by block 124 to simulate die 

Reference is made to Ser. Nos. 07/666,072 now abandoned Y machine in accordance with the selected mode and the 

and 07/665,652 now U.S. Pat. No. 5339,422, for more currcntYmachinc state. One or more Y instructions are then 

detailed disclosure of the detector and jacketing systems 106 55 executed in the Y domain by the simulator on the X 

and 108. hardware. 

The environment manager 102 manages the flow of Block 126 next provides for loop termination and return 

execution control between domains and for this purpose according to detected conditions returned from die simulator 

exercises supervisory control over the callable simulator 104 104 after its operation has terminated. If the Y program 

and the debugger 110 through the execution of a driver loop 60 counter is determined to be out of bounds previously estab- 

112. Support routines 114 provide various services to the lished as containing Y code and data, as indicated by block 

debugger 110 and the simulator 104. 128, a test block 130 determines whether the Y program 

The suppOTt routines 114 include a suitable initialization counter is making a return to the caller X program, 

procedure, suitable illegal address mapping, cross-domain If the Y program counter matches the distinguished return 

prc-check for debugger operations, and partitioning of 6S address in the block 130. the Y routine has completed and is 

domain address space for debugger, cross-code call detector making a return to its X caller. Block 132 then provides 

and simulator operations. The set of memory address ranges jacketing services, by copying values as appropriate from 
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the Y results rcgistca:(s) to the X domain. Normally jacketed This modular or phased debugging process makes debug- 

calls are processed with the jacketing Ubles used to initiate ging more manageable and more convenient for several 

the original call. The previously referenced special jacketing reasons including the fact that the full functionality of the 

code is used for auto-jacketed calls. Simulation is complete final image is available to &e ported Y module 152. The 
at this point as indicated by exit block 134. s phased process is continued untU the entire X program is 

If the test block 130 determines that the Y program converted to an equivalent debugged Y program, 

counter corresponds to a jacketing table entry and does not In addition to enabling advance debugging as previously 

match the distinguished return address, a call is made for an described, the present invention greatly facilitates the 

X routine (in the absence of a programming error). Block debugging process itsdf. Generally, user level code for the 
136 then providesjacketing services, by initiating a Y-X call, to X and Y and, if desired, other architectures may be fteely 

and the jacketing system 108 accesses the jacketing tables to intermixed for execution and debugging by systems embod- 

obtain the information needed to copy parameters from the ied in accordance with the invention. 

Y-domain to the X domain, the address of the X routine The Y appHcation program part 152, which may include 

being caUed, etc. When a return is made from the X routine, multiple source files corresponding to respective routines or 
the return value is copied into the Y domain and simulation 15 subprograms, is processed by a Y cross compiler 156 to 

IS resumed as indicated by path 137. produce one or more Y object files 157. Similarly, an X 

Mth reference again to block 126, if the STEP mode had con^)iler 158 processes Ac X program part 154 to produce 

been requested and die simulation termination is accordingly an X object image 159 having multiple X object files, 

determined to be a case called "Step Done", as indicated by a cross linker program 160 combines Y object files by 
block 138, functional block 140 caHs the debugger 110 to 20 providing ctoss file linkages between calling and called Y 

indicate completion of tiie requested step operation and pass object files (routines) in accordance witii ^plicable calling 

tiie previously returned status and the variable ENV_CMD. conventions for the Y architecture. An X linker program 162 

Aretum to the simulator 104 over path 137 enables resumed similarly combines X object files, 

^ulation without requiring direct simulator recall by the ^mcc Y object files (routines) may make cross domain 

oeDugger llU. execution of X object files (routines), and vice 

The debuggo- 110 interprets die status and may make a versa, an X-Y call interface is integrated with the Y object 

report to the user. Additional step operations are requested files and the X object files respectively by the linkers 160 

by the debugger 110 in accordance with a previously estab- and 162 tiicrcby facilitating cross-domain execution switch- 

lished internal script or by user selecti on. The driver variable ing at run time. SpecificaUy, Y jacket object files 161 and X 

ENV_CMD is set to RUN or STEP according to debugger jacket object files 163 are respectively Unked with tfie Y 

'^^^"^sts. object files and tiie X object files by the linkers 160 and 162. 

The debugger 110 calls tiie environment manager 102 to in the present embodiment, source code 151 for tiie 

perform otfier inquiry and status control functions (such as environment manager 102 is compiled at 153 to generate X 
set BREAKPOINT) as more fuUy considered in tiie cross- 3^ object files 155. The X linker 162 also links tiie environment 

referenced application Ser. No. 07/665,888, now abandoned. manager object files 155 witii other object files in producing 

Simulation is controlled only by ttie driver 112. a combined X image 167, 

If die simulation is due to an abort 142 or a breakpoint 144 The Y cross linker 160 is combines Y object files togetiier 

or Y errors 146, block 148 calls tiic debugger 110 and into a single image. AY image is generated by the Y linker 

operates in tiie manna: described for tiie block 140. that contains Y code but is externally formatted as a standard 

PROCESS FOR CREATING OPERAHONAL shareable X image. 

PROGRAM SYSTEM ^ preferred embodiment, a global data system is 

, . „^ ^ employed so that each code X or Yean generally access all 

Afunctional blockdiagrammnG.3rqiresentsaprocess data. However, protected locations may require special 
150employedintiieprefeiredembodimentoftiieinvention 45 processing for cross-domain access fi-om tiie Y domain, 

to aeate tiie system of programs tiiat are stored in the ^ -^^^^ descriptions 165 are 

memory 14 and operate as component parts of tiie multi- ^ by die user for each X and Yroutine on tiie basis 

rft'^i^^';^^ ? '''' u^^^^f^ "^'"^"^ ofknowledgeoftiieapplicableXandYcaUconventions.In 

10. Although tiie system user may generaUy enter programs embodiment, a pair of jacket descriptions is 
ofanylevcl fordebuggmg orotiie^ 50 prepared for each routine, i.e. one tiiat appUes to tiircalling 

Fogram at tiie user level is employed m tiie process 150 ^ j^,, caU^ domain, 

tiie application program to be entered into tiie system 10 . 1^ - , * ^ 

sinceitclearlyiUusfratestiieoperationandadvantag^^ h„^H '^H^fw ^r'^'t"^ 

present invemion jactetmg tables which can be mterpreted by ottier 

A.j..-il ^.^ , software atruntime to ^ectjacketing operations needed for 
AS moicatea me appHcation program to be entered is 55 cross-domain execution. A more complete descrintion of 

dividMl into a Y program part 152 and an X program part jacketing and cross^omain call detection is provided in the 

154. For example, in migrating an easting X user level cross-ieferenced appUcations Ser. Nos. OT/666,072, now 

architecture well in advance of the avail- abandoned and 07/665.752 now U.S. Pat No. 5339,422. 

f^^""" ''^^T'^'^'^^u"' AnXloaderorimageactivatorl«81inkstheYimagel64, 

f^.T.^^lEL°^.'^''^^'^ff'^'°'''°^'''^ theXimagclW.Sagemforthedebugger^Znda,^ 

l^Ji M^TZJT- "L** J;;o progiam parts ^ ^ ^ ^ X 

S n^tiSLTn thfv nr«l ' ^^"^ « ^^^^ X memory uZi formed into 

be performed on the Y program part 152. executable code. 

Subsequently, an additional modular part of the X pro- 

gram can be compiled to a new Y program part which is then 65 SYSTEM OPERATION 

entered with the debugged Y program part and the remaining A mixed or multi-architecture run-time environment 

X program part for debugging of the new Y program part exists at lun-time for the system 10 (FIG. 1) as a result of the 
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loading operation Just described. In the multi-architecture With reference to FIG. 4 again, once a cross-domain X-Y 

environment, Y code under test is able to call out to X code call is detected, the environment driver loop 112 (FIG. 4) is 

for convenient use and fiiU speed execution of available entered at 118 to start simulator driver loop execution and 

facilities and services that are operational and not under test the jacketing system 108 operates (block 120) to jacket the 

The loaded Y image contains all of the binary Y code to 3 call data (callol address, iiy)Ut/ou^ut parameters, etc.) for 

be executed by the simulator 104 with no external references transfer from the calling routine in the X domain to the 

to other images and no run-time fix-ups. Additional Y code called routine in the Y domain. 

supports the Y environment to facilitate access to every If the debugger 110 is inactive, block 122 requests a RUN 
cailabic routine in the Y image, to compute the address of a status for the simulator 104, and block 124 calls the simu- 
taiget routine at run-time, to provide a Y hardware context lO lator as previously described. Simulator execution of Y code 
block for the simulator 104 (FIG. 1)^ to provide control over then continues until a return is made as described in con- 
indirect calls from the Y domain, and to provide proper nectionwithFIG.4.Across-domain switch occurs if a return 
delivery of Y exceptions after formatting in the X domain. is made by the block 132 or if an X call is made by the block 

Once the simulator 104 is invoked to commence 136. 

simulation, execution of Y instructions continues until the If the debugger is selected to be active, code execution in 

simulator 104 can proceed no further. Apart from exception either the X or the Y domain can placed in the STEP mode, 

conditions, instruction execution normally stops when the In the Y domain, the block 122 (FIG- 4) sets the simulator 

simulator 104 generates a target instruction address outside status to STEP mode and STEP operation occurs as prcvi- 

the predetermined Y code range. ously described. 

The Y domain has no memory management function since Qt^er debugger commands are implemented through the 

memory management is performed in the X domain. environment manager 102 for application by the simulator 

The loaded X image includes user jffogram modules, 104 to the Y environment. Code breakpoints can be set, 

which is code from an application that the user has chosen canceled and listed for debugging purposes. Memory access 

to keep in X code rather than have it ported to Y code. is provided by EXAMINE and DEPOSIT conmiands to 

Jacketing data tables, compiled as previously described, enable the user to inspect and modify memory locations, 

provide data used at run-time to enable routines in one More detail on debugger and simulator operation is set forth 

domain to call routines in the other domain. The tables also in the cross-referenced applications Ser. Nos. 07/665,888, 

enable data rcfa:cnces from Y code to be intercepted for now abandoned and 07/66(5,022 now abandoned, 
processing, such as to access protected data in the X domain 

for use in the Y domain. SYSTEM FOR DBTECTING CROSS-DOMAIN 

In addition, the loaded X image includes Y routine entry CALLS 
points. Such points are jacketing routines provided for X to 

Ycalk and Y to X calb. Transtoed mdudes input and „^efocusedpffspe«We of the cross-code detec^n system 

output parametos and completion stetos values te return 35 lo*. QeneraUMi^acketing system 108 provides the jack- 

from the caUed domajn to the caUing d^niain^ X to Y call ^ ^ ^ J ^le X or Y dom;dn to 

mvokes Operation of the callable smiulator 104 for reception *u ^i. v v j * j • « u u 

of the 'ac±eted data ^ ^ Y or X domam once a cross-domam call has been 

. { . * . . ^ ^ . . , detected by the detection system 106. 

A debugger miage provides for operation of the debugger , , . « . . . , 

UO. It functions in both or either of the X and Y environ- ^ '^^^^^-^^ f ^ switch in the code 

ments. For example, it displays both X and Y instructions execution from one domam to the other domam (i.e a call 

symbolicaUy and sets breakpoints in the X and Y code. If ^^^^^ of a <xoss-domain routmc). A CTOss-domam 

desiied.thedebuggercanbedeactivatedwhenthesystemis also require processmg of a cross-domam dau 

used only for execution of mixed code without debugging. "» ^ ^'."^y ^ « ^""^ ^ 

rr^ .^^1. X -I AX *: V LI _*,uy_r domam to read or wnte catam memory locations assigned 

To stat^the system 10 for qpaatton^s^^^ 45 4, ^ though the X and Y memcry 

^T^'^'^r 'tf f ^J°f^ " addresses in the memory 14 are generaUy glob«S 

X code execution contmucsifthe next code module contams accessibl ^ o / & ^ 

X code, Otherwise, the next code module contains Y code . ... ... 

and the cross-domain detector 106 identifies the need to When X code 300 reaches a pomtm code execution by the 

switch execution from the X domain to the Y domain. If no 50 ^ process^ 12 (HO. 1) where a switch is to be made for 

XappUcation code is provided in aparticularuse, the system execution of a routine in the Y domain, the caU detection 

10 is directly switched to Y code execution and cross- system 106 causes the jacketing system 108 to jacket the caU 

domain calls from the Y code could then be made for ^ <*river loop 112 initiates operation of the Y simulator 

execution of X support routines. and execution of the targeted Y routine. The simulator 

m FIG. 5, there is shown a diagram iUustrating the « 104 accepts the jacketed caU a^^^ 

switching operations for mixed code execution. A sample "^^^ of Y code 302 m the Y domam. 

multi-code program includes three modules each containing A caU for a return to the X domain is then made by ttic 

a number of routines. In module A, an X code routine Al simulator 104 and call detection and jacketing provide for 

calls a Y code routine Bl in module B. An execution switch sending the return to the X domain, 

is made to the Y domain and, in the course of execution, the 60 In the X to Y direction of code switching, two different 

routine Bl calls another X code routine CI in a module C. detection mechanisms are employed for determining when a 

^th execution control switched across domains to the cross-domain routine call is to be made. A medianism 350 

module C, X code execution continues to the termination of manually detects X calls for execution of Y routines, and 

the routine CI. another mechanism 352 automatically detects certain other 

A domain switch is then made by a return back to the Y 65 X calls for execution of Y routines, 

routine Bl. The routine Bl completes and a cross-domain The mechanism 350 is termed a "manual*" detector since 

return is made to the original caller Al. the detection is produced by structure inserted into the X 
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code during the X image building process described in CROSS-DOMAIN CALL JACKETING SYSTEM 

connection wittina 3 Thus, an X-Y stub or Xroutine 354 ^ functional block diagram in FIG. 7 focuses on the 

IS inserted into the X code at each ofpreselectedpoints in the nianner in which cross-domain inteifadng is achieved 

SpcdficaRy, HG. 7 shows the manner in which cross- 
the Y domain. 5 domain execution calls are detected, jacketed, passed for 

The X stub routines 354 may be employed in those cases execution, and returned upon conq)letion of execution, 

where the address of the called routine in the Y domain is When X code 300 reaches a point in code execution by the 

known at link time. A separate one of X stub routines 354 is X processor 12 (FIG. 1) where a switch is to be made for 

provided for each callable Y routine. In effect, the X stub execution of a routine in the Y domain, the call detection 
routines 354 arc surrogate routines that transmit the Y lO system 106 employs a hardware fault intemipt or a stub 

routine call to the jacketing system 108. The X stub routines routine structured into the X code at link-time to detect the 

354 provide a combination of very fast detection and very call for execution of a Y routine. The jacketing system 106 

fast access to jacketing tables which support general jack- jackets the call as the driver loop 112 Initiates operation of 

eting capabilities. the Y simulator 104 for execution of the targeted Y routine. 

The X stub routines 354 provide two basic functions : load In the preferred embodiment, tiie X call may be detected 

a jacket index code onto the execution stack, and junq) to a by a hardware trap or by a stub routine structured at 

common entry point in the environment manager 102 to link-time into the X code. Once aroutuie call is detected, tiic 

carry out the X-Y call indicated by that index value. Thus, jacketing system 108 jackets the call by reference to the 

detection of an X-Y cross-domain call by an X stub 354 jacketing Ublcs. The simulator 104 accepts the jacketed call 

occurs by the fact that execution has reached that X stub 354, and executes the called routine in the Y code 302 in the Y 

The automatic detection mechanism 352 is a hardware domain, 

trap that employs X instruction fault hardware 356 to issue A request for a return to the X domain is made by the 

an exception when a cross-domain call occurs. The excep- simulator 104 and call detection and jacketing provides for 

tion is interpreted and processed by the environment man- sending the call return to the X domain. Execution of the X 

ager 102 for jacketing of the call by the jacketing system code 300 by the X processor 12 is tiien resumed. 

108. The automatic detection mechanism 352 is employed If the Y code 302 is being executed by the simulator 104 

for dynamicaUy con^juted calls, Le., where it is not known and a point is reached in tiie Y code where a switch is to be 

at link time whetiicr a particular caU is a cross-domain calL made for execution of a routine in the X domain, the call 

The automatic mechanism 352 works no matter which detection system 106 detects the cross-domain caU and 

domain contains the called routine. As shown in FIG. 6, causes the simulator 104 to initiate jacketing of tiie call. In 

routine 358 handles X to Y calls detected by tiie stub the preferred embodiment, tiie Y caU is detected by an 

stnicture 354 and the instruction fault hardware 356. address range routine or by a common stub routine struc- 

Block 360 indicates tiie passing of a call jacketed by the tured at Unk time into the Y code. Again, tiie jacketing 

jacketing system 108 to the simulator 104 for execution of system 108 jackets tiie call by reference to tiie jacketing 

the taiget routine in the Y domain. Once tiie target routine is tables. 

executed, a return is made for jacketing and transmittal to The targeted routine in tiie X code 300 is tiien executed by 

tiie X domain as Indicated by blocks 361, 362 and 364. tiie X processor 12. Once tiic execution of tiie targeted 

Cross-domain calls for execution of an X routine are routine is completed, a return call is detected and jacketed 
made during execution of Y code 302 by ttie simulator 104. ^ and sent in the X to Y direction across the domain boundary 

When a point is reached in tiie execution of tiie Y code 302 in ttie manner previously described. Hie Y simulator 104 

where an execution switch is to be made to tiic X domain, restarts to resun^ execution of the Y code 302. 

tfie call detection system 106 detects tiie cross-domain call The call jacketing system 106 also jackets calls for 

and causes tiie simulator 104 to initiate jacketing of tiie caU processing of cross-domain daU references. In tiiis 

by tiie jacketing system 108. embodiment, such data references may include a request 

The target X routine in the X code 300 is tiien executed, from the Y domain to read or write certain memory locations 

and a return is processed and jacketed to the simulator 104 assigned to flie X domain (even tiiough the X and Y 

which then resumes execution of ttie Y code 302. memories are generally globally accessible). 

In the present embodiment, a mechanism 366 is employed The jacketing of calls from one domain to the other 
for detecting all Y to X cross-domain routine calls. Checks 50 domain is effected by run-time routines that are driven by the 
368 are preferably en^)loyed against the Y address range to jacket tables created at image build time, as previously 
detect most Y-X calls since most rrferenced addresses are indicated. The ruo-time jacketing code and data are pro- 
known at linktime, A special stub 368C is preferably duced by tiie JDL compiler and combined into the X and Y 
employed for dynamically computed calls. codes by the linkers. 

Routine calls arc passed by the check structure 368 to the 55 Jacketing requires that knowledge of all of the relevant 

simulator 104 as indicated by block 370. An address range calling convention characteristics for each subprogram in 

routine 374, one of the support routines 114 (HG. 1), is then each domain be available to the jacketing mechanism. In the 

called to determine which domain contains the address of present embodiment, the previously noted jacket tables are 

the target routine. created and integrated witii Oie X and Y images at link time 

If the X address range is found, a return is made to the 60 so that calling routine and called routine conventions can be 
driver loop 112 in the environment manager 102 for cross- determined for proper call passing across the domain bound- 
domain call processing. A Y-X call is thus passed for ary between any X or Y routine and any Y or X routine, 
jacketing by the jacketing system 108 as indicated by the Each subroutine may have calling convention character- 
block 362. Once jacketed, tiie call is passed as indicated by istics tiiat are different from tiie characteristics of all otiicr 
the block 364 for execution of tiic target routine in the X 63 subroutines. The previously referenced jacket descriptions 
code 300. A return is made after tiie execution is completed are accordingly prepared for tiie respective subprograms in 
as indicated by block 372 and tiic block 360. the X and Y codes. 
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Generally, the jacket descriptioas describe Y routines that 
may be called from the X domain and X routines that may 
be caUed from the Y domain. Each description lists the 
described routine by name and defines die manner in which 
parameters are passed to and from the routine as previously 
indicated. Where the calling mechanism for a routine con- 
forms to the calling standard for the domain in which it is 
located, no linkage description need be associated with that 
routine. 

Each routine described has two descriptive parts, one for 
the calling domain side and one for the called domain side 
(the latter being where the actual code is found). Either or 
both of these descriptive parts can be implicit If no explicit 
linkage is given for a domain, an impHcit linkage description 
is assumed to reflect the calling standard for that domain. 

In the jacket tables, the jacket for eadi call from any one 
routine in one domain to any other routine in the other 
domain is thus defined by a pair of jacket description files. 
One file of the pair describes how the outgoing caller 
references the target, and the other file describes how the 
incoming routine expects to be referenced. Call linkage is 
implemented at run-time by the jacketing code. 

CALLABLE SIMULATOR 

The callable Y simulator 104 is shown in greater detail in 
FIG. 8. It provides a number of services to the software 
system 100 that may be classified into two categories: 
execution services and debug suppcHl 

When a system call is made for simulator execution from 
the environment manager 102 (FIG. 1), execution routines 
402 (FIG. 8) are called to direct execution of the Y instruc- 
tions and to provide returns under various circumstances, as 
more fully described hereinafter. Once the callable simulator 
104 is called to begin execution, it continues to execute Y 
instructions and updates the simulated machine state 
(context block and memory) until any of multiple predeter- 
mined conditions arise to step the execution and make a 
return to the caUer. A unique return status is returned for each 
return reason. 

State access routines 403 and BREAKPOINT routines 
405 are also induded in the simulator 104 to provide 
debugger services and are executed when a call is made for 
special functions provided by ttie routines 403 or 405. 

The machine state of the simulated Y architecture is 
contained in a single, globally-defined context block 404 
(FIG. 8). As shown, the context block 404 includes the Y 
program counter (PC) register 406 and all other Y registers 
408. 

The PC register 406 contains address data 407 of the next 
Y instruction to be executed. All instruction addresses, as 
well as all global data addresses 409 in the simulated 
architecture (Y) code, are located in shared address space in 
the conmion mcmoiy 14 (FIG. 2) for the multi-architecture 
system 10. No separate private Y code memory is main- 
tained by the simulator 104 whereas conventional simulators 
nonnally do maintain a separate private memory. With 
common memory and shared common addresses between 
the X and Y architectures, multiple architecture programs 
with global data structures shared between X and Y routines 
will execute propaly without modification. 

The initial Y machine state is set up prior to simulator 
operation by the environment manager 102 by writing to the 
context block 404 and by initializing program memory 407 
and 409. In particular, the address for the first simulated (Y) 
machine instruction to be executed is written to the PC 
register 406. 
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DEBUGGER 

When selected for use, the debugger 110 provides for 
debugging operations in both the X and the Y domains and 
^ is shown in greater detail in FIG. 9. In addition, portions of 
the common multi-architecture memory 14 most pertinent to 
debugger operation, and debugger related routines housed in 
other components of the software system 100 are shown in 

na 9. 

jQ A debugger execution program 200 is structured to be 
interactive with a user as indicated by block 202. 
Accordingiy, the user is enabled to detect and correct 
malfunctions in X or Y program code being executed by the 
multi-code execution and debugging system 10. 

15 Basic debugging functions are commonly provided by die 
debugger 110 for both the X domain and the Y dbmain. The 
procedures and mechanisms by whidi basic debugging 
functions are inaplemented are different for the X and Y 
domains. 

20 To provide for program malfunction detection and 
correction, the debugger progrMU 200 is further structured to 
inq}lement commands through domain dependent support or 
service routines 204 and general support routines 206. As 
indicated by block 208, the state of the active machine (X or 
25 Y) is set cither to STEP instructions or to RUN instructions 
in the code being executed. 

Various debugger support routines 210 are housed in the 
simulator 104 and accessed through the control of ttie 
environment manager 102. Thus, address domain routine 
212 and a cross-domain pre-check routine 214 are accessed 
in the environment manager 102 to provide additional 
support for debugger operation. 

The address domain routine 212 determines whether an 
instruction address lies within the Y domain or the X domain 
as needed for simulator/debugging operations. 

The cross-domain pre-check routine 214 (FIG. 9) enables 
the debugger 200 to dctcamine whether the instruction about 
to execute (current program counts:) wiU cause a diange of 
code execution domain from X to Y or Y to X. 

40 

The simulator/debugger driver loop 112 (FIG. 4) is 
executed by the environment manager 102 to provide basic 
control over execution of Y code and for invoking the 
operation of the debugger for Y domain debugging as 
43 required. The memory system 14 contains the X and Y 
program codes 218 and 220 being executed by the native (X) 
architecture and the simulated (Y) architecture. Other 
memory contents related to debugger operations includes a 

Y domain address list 213, the breai^int tables 217 used by 
20 the simulat(H' 104 and by the debugger 110. and the state 219 

of the Y architecture program (i.e., the context block or 
register state of the simulated processor). 

In the {^esent embodiment of the invention, a program 
counter is provided for each domain. Specifically, an X 

55 program counter and a Y program counter are provided, and 
the X and Y program counters are essentially independent of 
each other. The X program counter is a register that contains 
the address of the next instruction as fetched by X hardware 
from the memory instruction list of the X code. The Y 

60 program counter is a register in the X hardware structured to 
be part of the Y simulator and it similarly contains the next 

Y instruction as fetched by the simulator from the memory 
instmction list of the Y code. 

Various modifications and variations can be made in the 
65 improved system and method for executing multiple codes 
multi-architecture environment with code debugging capa- 
bility of the present invention by those skilled in the pcr- 
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taining art without departing from the scope and spirit of the 
invention. It is accordiagly intended that the present inven- 
tion embrace such modifications and variations to the extent 
they come within the scope of the appended claims and their 
equivalents. • ^ 
What is claimed is: 

1. A method for creating a mixed code program for 
execution in a multiple code execution system that provides 
a multi-architecture environment induding a real X archi- 
tecture and a simulated Y architecture, an input X code jq 
provided with a plurality of X code modules having plurality 

of X routines; an input Y code provided with a plurality of 
Y code modules having a plurality of Y routines, said 
method comprising the steps of: 
preparing a plurality of jacket descriptions defining call- 15 
iog conventions for incoming and outgoing calls for 
each said X routine in an X code module and for each 
said Y routine in a Y code module to be executed by 
said multiple code execution system, said calling con- 
ventions defining cross-domain interfacing between 20 
said X and Y routines, said jacket descriptions indud- 
ing identifications of call type, of a plurality of param- 
eters usable in said calls, of a call result memory 
location for containing call results, and of a routine 
memory location for containing information to be pre- 25 
served during said calls; 
compiling a plurality of X jacket objects and aplurality of 
Y jacket objects from said jacket descriptions, each of 
said jacket objects including a jacket table embodying 
the corresponding jacket descriptions for said routines; 30 
conq)iling a plurality of X objects from said X code 
module and a plurality of Y objects from said Y code 
module; 

linking said X objects and said X jacket objects to produce 
an X image, said X image including code utilizing said 3$ 
cross-domain interfacing for enabling interactive mul- 
tiplQ code execution and debugging; 

linking said Y objects and said Y jacket objects to produce 
a Y image; and 

activating said X and Y images for interactive execution ^ 
as said mixed code program in said execution system 

2. The method in accordance with claim 1, further com- 
prising the steps of: 

conq)iling a plurality of X objects from code for an 
environment manager component included in said mul- 
tiple code execution system; 

Unking said X environment manager objects with said X 
objects and said X jacket objects in said X image; 

generating an X image for a debugger component 
included in said multiple code execution system; 

generating an X image for a simulator component 
included in said multiple code execution system; 

activating said Y image and said X image and said 
debugger component image and said simulator com- 55 
ponent image for interactive execution of said X and Y 
modules under control of said environment manager, 
debugger and simulator conq)onents in said multi- 
architecture environment. 

3. The method in accordance with claim 2, wherein said ^ 
multiple code execution system includes an X computer 
system and said method fiiither comprises: 

operating said simulator component to simulate said Y 

ardiitccture on said X con^uter; 
operating said debugger conqjonent to debug said X code 65 

and said Y code in said multi-architecture environment; 

and 



50 



managing operation of said simulating and debugging 
components and said X computer system to provide 
mixed X and Y code execution and debugging. 

4. The method in accordance with dalm 1, wherein said 
X and Y modules conqirise related parts of an application 
program at a user level. 

5. A system for ^ecuting multiple codes interactively in 
a multi-architecture environment including a real X archi- 
tecture (domain) for executing X code and at least one 
additional simulated architecture (domain) for executing Y 
code, said multiple code executing system further compris- 
ing: 

an X cono^uter system having saidX architecture embod- 
ied therein for executing X code including a plurality of 
X routines; 

a memory coupled with said X computer system having 
stored X code and Y code; 

means, included in said X computer system, for simulat- 
ing said Y architecture on said X computer system to 
execute Y code including a plurality of Y routines; and 

means coupled with said X computer system for manag- 
ing operation of said simulating means and said X 
computer system to provide interactive execution and 
debugging of said X code and Y code by switching 
execution between said X code and Y code in response 
to a plurality of cross-domain calls between said X 
code and said Y code from a calling routine to a called 
routine thereof; said X and Y domains having respec- 
tive X and Y calling conventions; 

means coupled with said X con:q)Uter system for detecting 
said cross-domain calls; 

means coi^led with said detecting means and said man- 
aging means for jacketing said cross-domain calls to 
provide an interface between said calling conventions 
of said calling and called routines in said domains; said 
jacketing means includes jacketing tables having inter- 
face descriptive data for each said X and Y routine 
comprising a called or calling routine,' and means for 
referencing said tables to set up a plurality of param- 
eters for processing by said jacketing means. 

6. The system in accordance with claim 5, wherein said 
interface descriptive data of said jack^g tables indude 
identifications of caU type, of parameters usable in said calls, 
of a call result memory location for containing call results, 
and of a routine memory location for containing information 
to be preserved during said calls. 

7. The system in accordance with claim 5, wherein said 
referencing means references said jacketing tables for deter- 
mining a memory location in said X domain from which 
parameters can be retrieved and for determining a memory 
location in said Y domain frx>m which ccHiesponding param- 
eters can be placed. 

8. The system in accordance with claim 5, wherein said X 
and Y routines indude user levd, application level code and 
comprise related portions of an application program. 

9. The system in accordance with claim 5, wherein said X 
routines indude at least one library routine. 

10. The system in accordance with daim 5, wherein said 
managing means includes means for calling said simulating 
means to execute each jacketed call. 

U. The system in accordance with claim 5, further 
comprising means for debugging said X code and said Y 
code during execution thereof, and wherein said debugging 
means indudes means for generating a RUN or STEP mode 
signal, and said managing mi&ans further indudes means for 
operating said simulating means in accordance with said 
RUN or STEP mode signal. 
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12. A system for executing multiple codes interactively in 13. The system in accordance with claim 12, wherein said 

a multi-architecture environment including a real X ardii- interface descriptive data of said jacketing tables include 

tecture conqjrising an X domain for executing X code and at identifications of caU type, of parameters usaHc in said calls, 
least one additional simulated arc^tectm^ comprising a Y , ^ ^^^^ ^ j^^ion for containing caU results, 
domain for execuUngY code, said X and Y^^^ 5 and of a routine memory location for containing information 
respective X and Y callmg convenUons, said multiple codes a x v aut^wi jr ^^^^^ wuuuiiuni miumimiuu 

executing system fiirther comprising: ^ preserved during said calls, 

an X computer system having said X architecture embod- ^ accordance with claim 12, wherein said 

ied tfierein including a processor for executing X code referencmg means references said jacketing tables for dctcr- 

induding a plurality of X routines; mining a memory location in said X domain from which 

means, included in said X computer system, for simulat- parameters can be retrieved and for detennining a memory 

ing said Y architecture on said X computer system to location in said Y domain &om which corresponding param- 

execute Y code including a plurality of Y routines; and eters can be placed, 
means coupled with said X computer system for manag- 15. The system in accordance with claim 12, wherein said 
ing operation of said simulating means and said X ^ X and Y routines include user level, application level code 

computer system to provide execution of said X code and conqmse related portions of an appUcation program, 
and Y code, said managing means switching execution i^^r^^ system in accordance with claim 12, wherein said 

between said X code and Y code m response to a xroutines include at least one Hhrary routine caUed by said 

plurality of cross-domain calls, each said cross-domain v ti j j 

call being made from a calling routine in a first of said i^"™?*^^' . , ,. ^ . 

domains to a called routine in the other of said domains, 1". The system m accordance with clami 12, whcrcm said 

eadi of said calling and called routines conq)rising one laanaging means includes means for calling said simulating 

of said X and Y routines; means to execute each jacketed call, 
means coupled with said X computer system for detecting system in accordance with daim 12, further 

said cross-domain caUs; comprising means responsive to said managing means and 

means coupled with said managing means and responsive included in said X con^uter system for debugging said X 

to said detecting means for jacketing said cross-domain code and said Y code during execution thereof, and wherein 

calls to provide an interface between said callmg con- said debugging means includes means for generating a RUN 

vcntions of said calling and called routines in said or STEP mode signal, and said managing means further 

domains; said jacketing means includes jacketing indudes means for operating said processor and said simu- 
tables having interface descriptive data for said X and 30 lating means in accordance with said RUN or STEP mode 

Y codes, and means for referendog said tables to set up signal, 
a plurality of parameters for processing by said jack- 
eting means. * * * * * 
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